\chapter{Einführung}
\label{intro}
\section{Terminologie}
In diesem Abschnitt werden die meist verwendeten Begriffe erklärt.

\subsection{Server}
Im Kontext dieses Projektes ist der Begriff \textit{Server} ein Programm (Software), welches mit anderen Programmen kommuniziert. Ein Client (siehe nächster Abschnitt) kann einem Server eine Anfrage schicken, welche diverse Rechenoperationen auf Seite des Servers auslöst. Das Resultat der Rechenoperationen wird anschliessend dem Client als Antwort auf die Anfrage zurückgeschickt.

\subsection{Client}
Im Rahmen dieser Dokumentation bedeutet der Ausdruck \textit{Client} ein Programm, welches mit dem Server kommuniziert. In den meisten Fällen ist der Browser (siehe weiter unten) gemeint wenn von \textit{Client} gesprochen wird.

\subsection{Comet}
\textit{Comet} ist ein globaler Begriff für eine Programmiertechnik, bei der die Anzahl an Serveranfragen minimiert wird. Das Ziel von \textit{Comet} ist, dass der Server dem Client-Nachrichten zuschickt, ohne dass der Client jede einzelne Nachricht explizit anfordert.

Der Name \textit{Comet} ist aus Konkurrenz zur Programmiertechnik Ajax entstanden. Beides sind ursprünglich existierende Haushaltsreinigungsmittel. Bei Ajax sendet der Server dem Client ausschliesslich Nachrichten auf dessen explizite Anfrage.

\subsection{Polling}
\textit{Polling} bedeutet, dass der Client in regelmässigen zeitlichen Abständen Informationen vom Server anfordert. Der Server schickt jedes mal eine Antwort, auch wenn keine neuen Daten verfügbar sind.

\subsection{Server-Push}
\textit{Server-Push} bedeutet, dass der Server dem Client eine Nachricht zuschickt, ohne dass dieser diese explizit angefordert hat.

\subsection{Streaming}
\textit{Streaming} ist ein kontinuierlicher Datenfluss zwischen Client und Server. Streaming wird meist für Web-Radio oder Web-TV verwendet, wobei der Server dem Client die Ton- und Bildinformationen fortlaufend überträgt.

\subsection{Framework}
Ein \textit{Framework} (englisch für "`Rahmenstruktur'') besteht aus bereits vorprogrammierten Komponenten, die dem Softwareentwickler das Programmieren vereinfachen sollen. Das \textit{Framework} kann entweder aus ein paar wenigen Grundbausteinen, oder kann auch aus einer kompletten Programmierplattform bestehen. Daher ist das Wort \textit{Framework} ein breiter und relativ undefinierter Begriff.



\section{Kontext}

\subsection{NetGame}
An der Hochschule für Technik und Architektur Freiburg wurde zu didaktischen Zwecken eine Webapplikation (NetGame) entwickelt, die auf spielerische Art das Funktionieren der Netzwerkschichten eins, zwei und drei demonstriert. Es handelt sich dabei um ein Mehrspieler Spiel, das mit einer gesamten Schulklasse zur selben Zeit durchgeführt werden kann. Die Lehrperson kann von ihrem Arbeitsplatz Netzwerkverkehr generieren. Aufgabe der Schulklasse ist, die entsprechenden Netzwerkpakete jeweils an die richtige Zieladresse weiterzuleiten.

\subsection{Google Web Toolkit (GWT)}
NetGame wurde mit Hilfe des Frameworks GWT entwickelt. GWT ist eine Webentwicklungsplattform von Google, die es ermöglicht JavaScript Webapplikationen in der Programmiersprache Java zu schreiben. Der geschriebene Java-Code wird hierzu vom GWT-Framework in JavaScript-Code übersetzt. 

Beim Netzwerkspiel NetGame wird der gesamte Netzwerkzustand auf dem Server simuliert. Damit die Clients stets über den aktuellen Stand des Netzwerkes informiert sind, schicken sie periodisch (z.B. alle 2 Sekunden) eine Anfrage an den Server. Der Server antwortet anschliessend mit einer Nachricht. Diese Methode verursacht unter Umständen unnötigen Netzwerkverkehr, welcher durch Nutzung von Push-Technologien vermieden werden könnte.

\subsection{Push-Technologien}
Push-Technologie bedeutet, dass der Client ohne explizite Serveranfrage vom Server Daten erhält. Es gibt unzählig verschiedene Push-Technologien, die auf diversen Protokollen basieren. Der heutige Trend zeigt, dass die Nachfrage einer solchen Technologie immer grösser wird. Im Rahmen dieses Projektes sprechen wir ausschliesslich über \textbf{Web-Push-Technologien}. Dies setzt zwingend voraus, dass auf Seite des Clients ein Webbrowser vorhanden sein muss.

\section{Zielsetzung}
Die Nutzung der Push-Technologien ist immer grösserer Nachfrage. Die Hochschule für Technik und Architektur Freiburg hat deshalb das Interesse, im Rahmen eines oder mehreren Semesterprojekten, die Möglichkeiten der aktuellen Push-Technologien zu studieren und diese auf das Didaktikspiel NetGame anzuwenden. In diesem Kapitel werden folgende Ziele genauer definiert:

\begin{enumerate}
	\item Recherche
	\item Prototyp Entwicklung
	\item Analyse
\end{enumerate}

\subsection{Primärziel: Recherche}
Hauptziel des Projektes ist, die aktuellen verfügbaren Push-Technologien zu \textbf{recherchieren} und zu \textbf{untersuchen}. Dabei soll jedoch eine veraltete oder wenig brauchbare Technologie vernachlässigt werden. Die recherchierten Technologien sollen auf folgende Punkte untersucht werden:

\subsubsection{Architektur}
Die wichtigsten Bausteine der erforschten Push-Technologien sollen schematisiert und dokumentiert werden. Dabei soll das Zusammenspiel von Clientseite, Serverseite und den einbezogenen Protokollen aufgezeigt werden. Bei jeder Architektur soll darauf geachtet werden, ob eventuelle massive Einschränkungen bezüglich Betriebssystem oder Webbrowser vorhanden sind.


\subsubsection{Verbreitung \& Relevanz}
Für jede Push-Technologie soll anhand von existierenden Projekten aufgezeigt werden, wo und wie häufig diese Technologie verwendet wird.

\subsection{Sekundärziel: Prototyp Entwicklung}
Falls sich im Verlaufe des Projektes herausstellt, dass die Auswahl der brauchbaren Push-Technologien relativ klein ist und sich schnell einzelne Technologien herauskristallisieren, soll ein \textbf{Prototyp der jeweiligen Technologie} erstellt werden. Dieser Prototyp soll das Grundprinzip der jeweiligen Technologie illustrieren. Im Kapitel \ref{prototyp-spezifikation} ("`Prototyp Spezifikation'') werden die Funktionalitäten der Prototypen definiert.

\subsection{Fakultativ: Analyse}
\label{fak-analyse}
Die angefertigten Prototypen sollen anschliessend \textbf{analysiert} und getestet werden. Dabei soll herausgefunden werden ob die Push-Technologie tatsächlich weniger Netzwerkverkehr generiert als die im NetGame verwendete Pull Technologie. Bei Pull Technologien werden ausschliesslich Daten an den Client geschickt, wenn dieser die Daten explizit anfordert. Eine Bewertung und Schlussvolgerung der einzelnen Technologien soll aufgrund der Analyse geäussert werden.


\section{Projektphasen}
In diesem Kapitel werden die Zielsetzungen in Projektphasen aufgeteilt. Im Weiteren wird der Projektaufwand in Wochen (P1 - P12) gerechnet. Jede Woche bedeutet einen Arbeitsaufwand von acht Stunden.

\subsection{Phase 1: Recherche}
In der Recherchephase werden alle recherchierten Push-Technologien zusammengetragen und dokumentiert. Die Recherchen sollten frühstens in der fünften Woche (P5) und spätestens in der siebten Woche (P7) abgebrochen werden. Wann genau die Recherche abgebrochen wird, entscheidet der Fortschritt der Recherche. Falls sich ziemlich schnell klarstellen sollte, welche Technologien sich am besten eignen würden, kann schon früh mit der Entwicklung eines ersten Prototypen begonnen werden. Sollte sich jedoch im Verlaufe der Recherche klar stellen, dass viele verschiedene Technologien für das NetGame in Frage kommen würden, wird die Recherchephase um zwei bis drei Wochen verlängert, damit mehr Zeit in die Recherche investiert werden kann.

\subsection{Phase 2: Prototyp}
Der oder die Prototypen sollen ein konkretes Beispiel der Push-Technologie vorzeigen. Dazu sollen jeweils die entsprechenden Frameworks und/oder Programmiersprachen benutzt werden. Für die Prototypentwicklung wurden \textbf{vier bis sechs Wochen} eingeplant.


\subsection{Phase 3: Analyse}
Für jeden Prototyp soll der generierte Netzwerkverkehr mit einem Netzwerkanalysetool gemessen werden. Der gemessene Netzwerkverkehr soll anschliessend dokumentiert und mit der aktuellen Version des NetGame verglichen werden.

\newpage

\subsection{Phase 4: NetGame}
NetGame wurde absichtlich nicht in die Planung miteinbezogen (siehe Anhang \ref{planning-apendix}), weil zu diesem Zeitpunkt nicht gesagt werden kann, wie schnell die Recherchearbeiten und die Prototypentwicklung im Verlaufe dieses Projektes vorangebracht werden können. Falls das Projekt wesentlich schneller vorankommen sollte als geplant, soll ein konkreter Änderungsvorschlag für das NetGame ausgearbeitet werden. Beim Konzeptvorschlag wird die Verwendung des GWT-Frameworks priorisiert, da die aktuelle Version des NetGame bereits mit dem GWT-Framework umgesetzt ist.

